• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention describes mechanisms for, in a network of transparent bridges endowed with learning functionality of roads of type arp-path, in cooperation with the sdn controller, repair all the roads in use that pass through a certain link when it fails. The bridge with the link in error informs the controller sending an openflow packet of type packetln containing the destination address to be repaired. The controller queries in a table the border bridge to which each terminal is connected and sends an openflow packetout packet to the frontier bridge connected to the destination terminal. This package contains a multicast repair frame that the bridge de-encapsulates and sends through all its links, flooding the network until reaching the bridge that detected the failure of the link, establishing this frame as it passes through the network a confluence tree towards the bridge of the destination terminal. (Machine-translation by Google Translate, not legally binding)
    公开号:ES2647665A1
    申请号:ES201600530
    申请日:2016-06-24
    公开日:2017-12-26
    发明作者:Guillermo IBÁÑEZ FERNÁNDEZ；Joaquín ÁLVAREZ HORCAJO；José Manuel ARCO RODRIGUEZ；José Manuel GIMÉNEZ GUZMÁN
    申请人:Universidad de Alcala de Henares UAH；
    IPC主号:
    专利说明:

    DESCRIPTION

    Cooperative procedure, between bridges and controller, of repair of failed roads and network bridge.
     5
    Technical sector

    The present invention falls within the field of communications and electronic devices and / or computer applications that establish communications between transparent bridges. 10

    State of the art

    Note.- In this description the function called "terminal" normally identifies an end system but may be implemented in an intermediate system (bridge or router).

    Road establishment protocols known as Fast-Path and ARP-Path are known [MacCrane_10] [Tanaka_10] [NISHIMURA] [Mickenberg_11] [lbáñez_09] [Rojas_15] that establish paths by simultaneously exploring the entire network through a broadcast frame such as the ARP Request, an ARP Reply unidestine frame and learning on the bridges across the source MAC addresses and their association with the port through which the broadcast frame is first received.

    These protocols have the disadvantage that when a link fails, a Path Request broadcast frame is sent over the entire network to be sure to reach the destination border bridge, said bridge then generates a broadcast Path Reply frame that establishes tree paths to said destination terminal, the frames directed to said terminal that are in the network will follow the branch towards the destination that reaches the bridge they are crossing (the bridge with the failed link). This fully distributed repair procedure has the disadvantage that it involves processing on all bridges in the Path Request network until the destination bridge is reached.

    It is also known to use one or more network controllers in Software Defined Networks (Software Defined Networks, SDN) [OpenFlow-1.3.2] connected to each of the bridges of the network through a parallel control network.

    SDN bridges can be hybrid [OpenFlow-1.3.2] by combining the traditional (distributed) bridge forwarding functions and 40 routers in various ways with the (centralized) forwarding functions managed by the controller. In these bridges part of the incoming traffic is processed by the distributed functionality implemented in the bridge or according to the treatment explicitly specified by the controller to the bridge for each traffic flow.
     Four. Five
    These SDN networks perform the repair of faulty roads in a fully centralized manner, the bridge communicating to the controller the failure of one of its links. The controller calculates alternative routes for the destination terminals affected by the failure of said link and configures through its control interface (for example OpenFlow) a new path to the destination terminal on each of the bridges crossed by the new path. This procedure has a significant processing delay to calculate and configure the changes in the processing tables in the bridges for the frame flows affected by the fault. It also requires that the active topology of the
    network is free of redundant links so that broadcast frame forwarding does not generate frame storms.

    The invention described in this patent mitigates the disadvantages of distributed repair and avoids those of centralized repair, by means of a cooperative repair procedure between the network bridges and the controller. The controller prepares the repair frame and sends it to the destination border bridge, which only uncapsulates it and forwards in multicast through the network, thus restoring the path to the destination terminal when the source address of the destination terminal is learned on the bridges. 10

    Explanation of the invention.

    Frame routing protocols based on road exploration such as ARP-Path, find the roads by flooding the network through broadcast frames. 15 The bridges that use them only learn the source MAC addresses of the ARP Request, ARP Reply and other control frames they receive, blocking the learning of those addresses in other ports of the bridge for a sufficient time and discarding the same frames origin received during that blocking period in other ports of the bridge. These bridges can be implemented as 20 bridges with SDN capability equipped with an OpenFlow interface, thus combining the functionality of an OpenFlow bridge with that of an ARP-Path bridge in a single bridge. This combined functionality has, on the one hand, the advantage of being able to avoid detailed control of all network data flows to the controller and in particular enables cooperative repair of roads between the network and the controller. 25

    The present invention describes mechanisms that allow, in a network of transparent bridges with OpenFlow Interface and equipped with road learning functionality with temporary blocking of ARP-Path type relearning, to implement the repair, in cooperation with the SDN controller, of all roads in use that 30 go through a certain link when it fails. Thus, when a link to a terminal on a bridge has to be repaired due to a link or other cause, it informs the controller by sending a Packetln OpenFlow package containing the destination address to be repaired. The controller consults in a table the border bridge to which each terminal is connected and sends an OpenFlow PacketOut packet to the border bridge 35 connected to the destination terminal. This package contains a multicast repair frame that the bridge uncapsulates and sends through all its links, flooding it until it reaches the bridge that detected the link failure, establishing this frame as it passes through the network a confluence tree where to reach to the bridge of the destination terminal, whose branches, one or more, will be used by the frames in transit 40 towards the destination.

    These mechanisms can be implemented in specialized hardware devices either partially or totally as software programs executed in both specialized and generic hardware devices. Four. Five

    Brief description of the drawings

    To complement this description, and in order to help a better understanding of the characteristics of the invention, a set of drawings is encamped as an integral part of said description, where, for illustrative and non-limiting purposes, the next:
    Figure 1 shows the four types of processing that a frame can have in a hybrid bridge: cooperative recovery, ARP-Path recovery, OpenFlow treatment and ARP-Path treatment.

    Figure 2 shows the last case of processing of the frame that can be given, 5 when the frame is treated with the ARP-Path protocol.

    Figure 3 shows the processing of the frame in the controller part.

    Figure 4 shows the processing of the frame when a cooperative repair 10 with Path Recovery frame is performed.

    An example of a network with an SDN controller is shown in Figure 5 where the control network (bridge-controller) is implemented with a separate network (out-of-band).
     fifteen
    Figure 6 shows a path established between terminals A and B, through the learned directions associated with ports on the different bridges that intervene on the road.

    Figure 7 shows a link failure linking bridges s3 and s5, so the frame 20 that terminal A sends to B upon arrival at s3 cannot be forwarded.

    Figure 8 shows how bridge s3 reports the problem to the controller with a Packetln frame.
     25
    Figure 9 shows how the controller sends a PacketOut frame to the s5 bridge destination of terminal B.

    Figure 10 shows how bridge s5 destination of B sends a Path Recovery frame to the entire network to learn again where it is B. 30

    Figure 11 shows the format of the Path Recovery recovery frame.

    Figure 12 shows how to send frames from terminal A to B by the new path. 35

    Figure 13 shows how after a while the learned and unused addresses are not refreshed and erased, as occurs in the s3 bridge.

    Figure 14 shows an example of network with SDN controller in which there is no separate control network 40 (in-band signaling) and where the sending of control frames to the destination bridge of terminal B fails.

    Figure 15 shows the sequence of packets and frames exchanged between the network elements, from the failure of the link linking bridges s3 and s5 until the path to s5 is repaired.

    Preferred Embodiment of the Invention

    All bridges in the network are bridges with OpenFlow and ARP-Path functionality. Figure 50 shows the generic operation of the OpenFlow bridge when a frame is received, selecting different actions according to the type of frame received.

    These actions are: process the frame as specified in the OpenFlow tables, process the OpenFlow PacketOut package received from the controller, execute cooperative road recovery, conventional ARP-Path recovery or forward frame according to the ARP-Path protocol, shown in Figure 2.
     5
    If there are no SDN rules configured on the bridge or ARP-Path routes to route the frame, according to the flow chart in Figure 2, connectivity to the controller would be checked and if no connectivity exists, ARP-Path distributed recovery would begin. If there is no regal configured, it is verified if the received frame is a Path Recovery frame to participate in the cooperative recovery process of Figure 4, where in 10 each bridge the address of the destination terminal is learned or updated.

    If the frame is not related to repair, it is treated as a normal ARP-Path frame according to Figure 2.
     fifteen
    In the event that the bridge generates a Packetln the controller will perform the provisions in Figure 3.

    Figure 5 shows a network in which an embodiment of the invention is collected, implemented in a network with a central SDN controller connected to the bridges with OpenFlow interface via a separate network.

    Terminals A and B are connected respectively to border bridges 1 and 5. These bridges have established paths between terminals A and b, as shown in Figure 6, by learning the source address of the ARP 25 Request frames and ARP Reply issued by said terminals when beginning to communicate. It is indicated, next to each bridge, with a circle surrounding a letter, the port to which the address of said terminal is associated (learned address)

    Accordingly, and similarly to other transparent Ethernet bridges, for a unidestinal frame with destination 8 leaving A, upon arriving at bridge 1, a memory of said bridge is consulted on the contents of the forwarding table for said destination address, reading from it the exit port through which it must be forwarded, the port of s1 that has a circle B in Figure 6; when the frame arrives at bridge 3 it is also forwarded to bridge 5 after consulting the bridge forwarding table and at bridge 5 35 it is forwarded by the port associated to terminal B. In all the crossed bridges the renovation or refreshment of the expiration timer of the destination MAC address, which allows the path to the destination to be activated.

    It is assumed that a path is established between terminals A and B, as shown in Figure 6, with the addresses learned in the different ports and a frame arrives at the bridge s3 and must be forwarded by the link s3-s5 that failed, as illustrated in figure 7. Bridge s3 does not have a valid route in its tables to reach destination terminal B or the forwarding port is disabled, so it informs the controller of the problem with an OpenFlow Packetln package, within which the address 8 of the unknown destination terminal goes, as shown in Figure 8.

    The controller has registered in a table the addresses of the terminals and the border bridges to which they are connected, check the bridge corresponding to terminal 8, in this case the s5 bridge, prepare a special Path Recovery frame of 50 road repair with the source address of terminal 8 and sends it encapsulated within a PacketOut frame, as shown in figure 9.

    The destination border bridge begins the recovery process, figure 10, without generating traffic to terminal B. The recovery is done by forwarding the Path Recovery frame, whose format is shown in Figure 11, with the destination address the group MAC address assigned to all AllPath bridges and in the Ethertype field the ARP-Path protocol identifier (or the SSAP / DSAP fields Source Service Access Point, Point 5 Access to the Source Service / Destination Service Access Point, Access Point to the Destination Service) used with the same purpose if the encapsulation is LLC (Logical Link Control, Logic Link Control) and with source address B.

    This Path Recovery frame is retransmitted, as shown in Figure 10, for all the ports except the one that received it first, discarding the duplicated frames that are received later in the same way as in the ARP-Path protocol, for being received by a port other than the one associated to its source MAC address. To do this, during this propagation, according to the organizational chart of the cooperative recovery of Figure 4, the address of B is learned in the learning table (Learning Table, LT) thus creating a confluence tree with root in the bridge 5, which will persist during the learning timer activation time.

    Figure 11 shows the recovery frame format with the Path Recovery frame type. Figure 12 shows how bridge 1 after learning the new port 20 to reach 8, sends the unidestine frame to B.

    Some entries in the table become obsolete when not used and are removed due to expiration of your timer, as shown in Figure 13.
     25
    The source MAC address of the terminal can be learned during the repair on ports that finally do not traffic to B, so, after a period associated with the entries in table LT, figure 2, the address expires and is deleted. In Figure 13, the bridge s3 deletes the address of 8 and the network with the address B is learned in the ports through which it is used by the traffic with destination B. 30

    This road repair is unidirectional to reach the destination terminal B. For traffic in the opposite direction a similar repair is made.

    If the data network is also used for communication between the controller and the 35 bridges, the cooperative repair may be affected by the link failure, and several cases and actions may occur in each case:

    a) Bridge-Controller link failure. If the bridge cannot send the Packetln package to the controller, the bridge can use any of the ARP-Path distributed repair methods described in the prior art, as shown in Figure 2.

    b) Failure of the destination Controller-Bridge link, in this case the PacketOut is sent to the origin border bridge and this bridge can use some of the distributed repair ARP-Path 45 methods, for example by sending a Path Request broadcast frame for destination B. answering the destination border bridge with a Path Reply frame. An example of this case is shown in Figure 14 in a shared network for data and control (inband) in which the link failure between s3 and s5 affects the communication between the controller and the destination border bridge, so that PacketOut does not arrive and distributed repair from the source bridge is necessary.



    References

    [MacCrane_10] Mack-Crane et al. Media access control bridging in a mesh network. Patent Application Publication. US 2010/0272108 A1
     5
    [Tanaka_10] Tanaka et al. First arrival port learning method, relay apparatus, and computer product. US Patent: US 7760667 B2

    [NISHIMURA] Nishimura K. WO / 2008/111173. Communication Path Control Method, Communication Apparatus and Communication System. Publication date: 18.09.2008 10

    [Mickenberg_11]. Minkenberg et al. US2011 / 0032825A1 Multipath discovery in switched Ethernet networks. Patent application Publ. date Feb. 10, 2011

    [lbáñez_09] Ibáñez et al. P200900508. Routing procedure of 15 data frames and network bridge.

    [Rojas 15] E. Rojas, G. Ibanez, J. M. Jiménez-Guzman, J. A. Carral, A. Garcia-Martinez, l. Martinez-Yelmo, JM Arco, All-path bridging: Path exploration protocols for data center and cam-pus networks, Computer Networks 79 (0) (2015) 120 - 132. 20 doi: http: //dx.doi.org/ 10.1016 / j.comnet. 2015.01.002. URL http: //www.sciencedírect.com/ science / article / pii / S1389128615000055

    [OpenFlow-1.3.2] OpenFlow Switch Specification v1.3.2, https: // www. opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/ 25 openflow-spec-v1.3 2. pdf.
    权利要求:
    Claims (8)
    [1]

    1. Cooperative procedure for the repair of data frame paths comprising:
     5
    - receiving, through a port of a network bridge where said port has an assigned port identity, a frame comprising a source MAC address and a destination MAC address;
    - Associate, in a recording unit, the originating MAC address of the received frame to the identity of the bridge port that first received the frame, an indication of the expiration of the frame and the moment of arrival of the frame:
    - delete, in the registration unit, the associations that a port of a bridge has when it detects the drop of a link in said port or the validity timer 15 of the address expires;
    characterized in that when a frame arrives at a bridge with a MAC address of unknown destination it comprises:
     twenty
    - send a special repair request frame to the controller, encapsulated in an OpenFlow Packetln package, containing the MAC address of unknown destination;
    - check the controller for the identity of the border bridge to which said destination terminal is connected;
    - build a repair frame with source MAC address that of the destination terminal and destination the multicast address of the ARP-Path protocol;
     30
    - encapsulate said frame in an OpenFlow PacketOut package and send it to the bridge connected to the destination terminal;
    - remove the destination border bridge the repair frame contained in the OpenFlow Packetln package and forward it through all the ports of the border bridge connected 35 to other bridges.

    [2]
    2. Cooperative method of repairing data frame paths according to claim 1, characterized in, on the bridges where the special Path Recovery repair frame is received:
    - Learn the new path by associating the source address of the received frame with the port through which Path Recovery is first received.

    [3]
    3. Cooperative method of repairing data frame paths, according to any of the preceding claims, characterized in that the road repair frames are selected from:
    - standard ARP Request and ARP Reply frames generated by the corresponding terminal or by an intermediate bridge; fifty
    - special repair frames: Path Recovery;
    - combinations of the above.
    [4]
    4. Cooperative method of repairing data frame paths, according to any of the preceding claims, characterized in that the address registration in repair process comprises the destination MAC addresses and a repair timer with an initial value greater than the time necessary for Repair frames run through the network and be answered. 5

    [5]
    5. Network bridge comprising processing means configured to:
    - send a special repair request frame to the controller, encapsulated in an OpenFlow Packetln package, containing the MAC address of unknown destination; 10
    - associating, in a recording unit, the source MAC address of the received frame with the identity of the bridge port that first received the frame, an indication of the expiration of the frame and the moment of arrival of the frame;
     fifteen
    - renew the address expiration timer of the destination MAC address for a new period in order to keep the unidirectional path to destination activated;
    - delete, in the registration unit, associations that have a port of a bridge when it detects the drop of a link in said port or the validity timer 20 of the address expires;
    characterized in that when a frame arrives at a bridge with an unknown MAC address address the procedure comprises:
     25
    - send a special repair request frame to the controller, encapsulated in a Packetln package, containing the MAC address of unknown destination;
    - check the controller for the identity of the border bridge connected to said destination terminal; 30
    - build a special Path Recovery repair frame with source MAC address that of the destination terminal and destination the multicast address of the ARP-Path protocol;
    - encapsulate said frame in a PacketOut package and send it to the bridge connected to the destination terminal:
    - extract the repair frame on the destination border bridge and forward it through all the ports of the border bridge connected to other bridges.
     40
    [6]
    6. Network bridge according to claim 5, characterized in, on the bridges where the special Path Recovery repair frame sent by the border bridge is received:
    - learn the new path by associating the source address of the received frame with the port through which the Path Recovery frame is first received. Four. Five

    [7]
    7. Network bridge according to claim 6, characterized in that the road repair frames are selected from:
    - standard ARP Request and ARP Reply frames generated by the corresponding terminal 50 or by an intermediate bridge;
    - special repair frames: Path Recovery;
    - combinations of the above.

    [8]
    8. A switched telecommunications network characterized in that it comprises at least one network bridge defined according to any one of claims 5 to 7.
     5

    类似技术:
    公开号 | 公开日 | 专利标题
    US9628285B2|2017-04-18|Increasing failure coverage of MoFRR with dataplane notifications
    ES2361545B1|2012-05-08|PROCEDURE OF FURNITURE OF DATA SECTIONS AND NETWORK BRIDGE.
    EP2839614B1|2016-10-26|Selecting between equal cost shortest paths in a 802.1aq network using split tiebreakers
    ES2527834T3|2015-01-30|Method and system of communications of services company
    KR20140027455A|2014-03-06|Centralized system for routing ethernet packets over an internet protocol network
    US8811168B2|2014-08-19|Transient loop prevention in a hybrid layer-2 network
    ES2540595B2|2016-02-02|PROCEDURE FOR ESTABLISHING AND DELETING ROADS AND FORWARDING SECTIONS FOR TRANSPORT CONNECTIONS AND NETWORK BRIDGES
    ES2306337T3|2008-11-01|PROCEDURE AND SYSTEM FOR IMPLEMENTING THE VIRTUAL ROUNDER REDUNDANCY PROTOCOL ON A RESILIENT PACKAGE RING.
    ES2731352T3|2019-11-15|Method and device for fault detection
    US20140328163A1|2014-11-06|Midspan re-optimization of traffic engineered label switched paths
    US8837329B2|2014-09-16|Method and system for controlled tree management
    WO2005015855A1|2005-02-17|Method of switching packets in a transmission medium comprising multiple stations which are connected using different links
    US20090129383A1|2009-05-21|Hub and spoke multicast model
    CN110120906B|2021-04-20|Method and device for realizing dual active access TRILL park edge
    WO2014132967A1|2014-09-04|Communication system, switch, control apparatus, control channel configuration method and program
    KR20130079596A|2013-07-10|Network configuration method, ring network system, and node
    ES2647665B2|2018-04-24|Cooperative procedure, between bridges and controller, of repair of failed roads and network bridge
    US9590889B2|2017-03-07|Multicast routing via non-minimal paths
    ES2638292B2|2018-04-17|Procedure for establishing and deleting multiple disjoint paths, frame forwarding and network bridge
    Sharma et al.2014|Meshed tree protocol for faster convergence in switched networks
    JP2014007568A|2014-01-16|Multicast forwarding system and multicast path switching method
    Kitsuwan et al.2014|A Europe-wide demonstration of fast network restoration with OpenFlow
    CN111049874A|2020-04-21|Using BIER to forward multicast packets for BIER-incapable network devices
    KR20150091637A|2015-08-12|Method for esasi pdu transmitting in trill network
    JP2009535871A|2009-10-01|Cascading out-of-box services
    同族专利:
    公开号 | 公开日
    WO2017220834A1|2017-12-28|
    ES2647665B2|2018-04-24|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    WO2015015505A1|2013-08-01|2015-02-05|Hewlett-Packard Development Company, L.P.|Address resolution rewriting|
    法律状态:
    2018-04-24| FG2A| Definitive protection|Ref document number: 2647665 Country of ref document: ES Kind code of ref document: B2 Effective date: 20180424 |
    优先权:
    申请号 | 申请日 | 专利标题
    ES201600530A|ES2647665B2|2016-06-24|2016-06-24|Cooperative procedure, between bridges and controller, of repair of failed roads and network bridge|ES201600530A| ES2647665B2|2016-06-24|2016-06-24|Cooperative procedure, between bridges and controller, of repair of failed roads and network bridge|
    PCT/ES2017/070443| WO2017220834A1|2016-06-24|2017-06-19|Cooperative method, between bridges and a controller, for repairing failed paths and network bridging|
    [返回顶部]